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We are developing DAQ for Si-pixel detectors by using a Slicon-On- 
Insulator (SOI) technology. This DAQ consists of firmware works on 
SEABAS (Soi EvAluation BoArd with Sitcp) DAQ board and software 
works on PC. We have been working on the development of firmware/software. 
Now we accomplished to speed up the readout 90Hz) and to add a func¬ 
tion for frame rate control. This is the report of our development work 
for the High Speed DAQ system. 
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1 Introduction 

1.1 SOI Detector 



® Rey. Hori 


Figure 1: The structure of SOI Detector. 


SOI Pixel detectors are being developed by a SOIPIX collaboration led by KEK. They 
are based on a 0.2 um CMOS fully-depleted (FD-) SOI process of Lapis Semiconductor 
Co., Ltd [T]. A detector’s structure image is shown in Fig[^ SOI detector consists 
of a thick and high-resistivity Si substrate for sensing part, and a thin Si layer for 
CMOS circuits [T]. An SOI detector has no bump bonding, therefore the application 
has low capacitance, low noise, high gain, and low material budget. It can run fast 
with low power. 



14.1 miTi 


For Examination of DAQ system, used the in¬ 
tegration type SOI pixel detectors, named INT- 
PIX4 [2]. The pixel size is 17jim squares, a num¬ 
ber of pixels are 832 x 512, and a sensitive area is 
14.1 X S.7mw?. This detector consists of 13 blocks 
(64 X 512 pixels / block) and each blocks has in¬ 
dependent channels of analog output for parallel 
readout. Photo of INTPIX4 is shown in Fig[^ 


Figure 2: The photo of INTPIX4. 
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1.2 SEABAS DAQ system 



Figure 3: The photo of SEABAS2. 



Figure 4: The working image of DAQ Software. 
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Figure 5: The schema of SEABAS DAQ System. 

INTPIX4 is read out through the board called SEABAS 2 (Soi EvAluation BoArd 
with Sitcp 2 |3]). SEABAS 2 is the 2nd Generation of SEABAS board. Figis the 
photo of SEABAS 2. 

This board has FPGAs for Gigabit Ethernet and a user circuit, and 12-bit ADC 
for convert detector’s analog output. When SEABAS2 transfer INTPIX4’s output 
after ADC conversion, total data size is 6,815,744 bit (ADC 12bit -|- padding 4bit 
= 16 bit per pixel) per frame. DAQ system consists of firmware work on SEABAS2 
user circuit FPGA, and software work on PC (shown in Fig|^. Between PC and 
SEABAS2 are connected by Gigabit Ethernet and communicate TCP/UDP protocol. 
The schema of SEABAS DAQ is shown in Fig[^ 
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1.3 Needs of High Speed DAQ 
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Figure 6: The schema of Readout 
from sensor. 


SOI Pixel sensor outputs a large quantity of data 
at a time. Fig|^is a simple schema of readout from 
sensor. For example, 6,815,744 bit/frame in the 
case of INTPIX4. Therefore, fast data transfer 
is important for quick and high resolution mea¬ 
surement. And if use DAQ for temporal response 
measurement, stability of transfer rate is also im¬ 
portant. 


2 Methods 

Our approach for high speed & stable transfer DAQ is total 3 points in software and 
firmware. 


2.1 Abstraction and Hierarchization 
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Figure 7: The Schema of Abstraction and Hierarchization. 


“Abstraction and Hierarchization” is the one of the refine approach in software region. 
The schema of this refine is shown in Fig[^ 

In existing system, all functions are controlled from GUI directly. And many 
function’s codes are written without classified. This situation causes confusion in 
software development, such as ’’Spaghetti Code”. 

Therefore, we refined this software structure. We separated function’s codes with¬ 
out directly related to GUI, and function’s codes were classified and concentrated 
to some classes and functions under DaqEnv class. All classes completes in its own 
as much as possible. DaqEnv is the abstraction class for absorbing all environment 
difference. GUI access every functions via DaqEnv class. 

This refine gives 2 merits. 

• Easy to add/delete function. 

We only have to fix related class’s code. Other codes are needless to touch. 
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• Easy to apply for any SOI Sensors. 

To apply this software for another sensor, only few codes need modify. 


2.2 Multi Thread (MT) Processing 


✓ 

/ 

\ 

\ 




Existing 
(Single Thread) 


4 


Refined 
(Multi Thread) 


CD 

c 

CD 
3 
O" 
CD 


Data taking 


CFIFO(std:nist^ 


Data Store 


Data taking 




Data Store 


Slow Process! 


Work in Parallel 


Figure 8: The Schema of Multi Thread Processing. 

“Multi Thread Processing” is the other one of the refine approach in software region. 
The schema of this refine is shown in Fig[^ 

In existing system, software working on single thread processing. In the case, data 
taking job this job is data taking from SEABAS and data store job are sequential. 
So next data taking job have to follow previous data store job. In result, DAQ whole 
efficiency is reduced. 

Therefore, we refined this software structure by using multi thread processing. To 
implement multi thread, we use WIN32API|1] and Posix ThreadlH]. 

Refined software’s structure consists of 2 threads, one is data taking job thread, 
and the other is data store job thread. These threads are working in parallel, so data 
taking don’t have to wait the other job. To pass data between 2 threads, use “First 
In, First Out (FIFO)” buffer based on std:dist[nj. This refine make it possible to 
take data at the maximum speed. From measured value, data transfer rate of refined 
software is three times as speedy as that of existing one. 
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2.3 Trigger rate control (TRC) 
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Figure 9: The Schema of Trigger rate control function. 

“Trigger rate control” is the refine approach in firmware region. The schema of this 
refine is shown in Fig|^ 

In existing system, frame data from sensor is taken one after another, without rate 
control. Because of this, sometime frame rate stability is broken when data transfer 
is delaying. To refine this problem, the flow control function is required. 

Therefore, we implemented some low frequency clock as “Trigger Control Clock 
(TCC)” to firmware. Role of this clock is rate control. 

The flow of the data taking sequence with trigger rate control is this way. 

1. When TCC raise up while waiting trigger, start data taking. 

2. While data taking and transfer, issuing of next trigger is postponed. 

3. After the end of data transfer, DAQ system will return to wait next trigger 
state. 

4. Repeat 1-3 until all frames are taken. 

When TCC is set lower than maximum data transfer rate, frame rate will be 
stabilized in fixed (synchronized to TCC) rate. 
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3 Results 


3.1 New DAQ Software 

We developed the new DAQ software refined from 
previous software. Introduced function, “Abstrac¬ 
tion and Hierarchization” and “Multi Thread”, 
was implemented. 

This software is using some libraries, Qt 5.4, 

OpenCV2.4.11 and picojson. Recent version of 
Windows (Vista, 7, 8, 8.1, both 32 bit and 64 bit) 
are supported. Linux will be supported soon. 

This software’s GUI was completely re¬ 
developed based on Qt library. This GUI is com¬ 
patible with previous GUI. Thus function’s codes 
can be transplanted each other between new GUI 
and old one. 

New Software’s working image is shown in Fig 

uni 

3.2 X-ray Imaging 

This is results of X-ray imaging data taken by new DAQ. The Specification of DAQ 
PG is shown in Table Fig is X-ray imaging data of the dried anchovy. And 
Fig is X-ray imaging data of the red pepper. We can see clearly the structure 
of sample. When we take this, frame rate is 65Hz, this is almost 94% of estimated 
maximum. And we can confirm new DAQ can take data correctly. 



Figure 10: The working image of 
new DAQ software. 


Element 

Value 

Model 

Lenovo XI Carbon Gen 3 

OS 

Windows 7 pro 64 bit 

CPU 

Intel Core i7 5500U 2.40Ghz 

Primary Disk (OS & Software) 

Intel SCKJF180A5L 180GB M.2(SATA6Gbps) SSD 

Storage Disk (Data Store) 

I-O DATA HDPC-UT2.0D (USB3.0) 

Ethernet 

Intel Ethernet Connection I218-V 


Table 1: Specification of DAQ PC used for X-ray imaging and TRC test 
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3.3 Trigger rate control Test 

We tested trigger rate control function. DAQ PC is same PC as X-ray imaging. 

The contents of the test is take a movie of blinking LED (2.4Hz, duty 56%), and 
count frames in one blink period. When taking data from sensor, set TRC function 
enable with 4 preset TCC clocks (10, 25, 50, 75 Hz, and Full Speed is noncontrolled). 
Frame’s count is related to the real frame rate. If TRC works correctly, frame’s count 
will change depending on selected clock. Fig is result of the test for check relation 
between selected clock and real frame rate. Figure’s horizontal axis is selected clock 
rate, vertical axis is frame’s count. 

We can see good relation between frame’s count in one blink period and selected 
frame rate. 
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Frame Count per Blink Period vs Frame Rate 



Figure 13: The graph of Frame’s Period vs Blink Frequency. 


4 Conclusions 

• Developed DAQ firmware & software for high-speed & stable readout. 

• Applied Abstraction and Hierarchization for DAQ software. 

• Implemented Multi Thread Processing for DAQ software. 

• New DAQ can high-speed data taking. (~ 90Hz, 94% of maximnm in X-ray 
Imaging) 

• Implemented Trigger rate control for new DAQ, and this function seems work 
correctly. 

• We confirmed new DAQ can take data correctly. 
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